stm32: xspi: Allow flash driver usage in RAM_LOAD mode #99729
+61
−36
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The following west manifest projects have changed revision in this Pull Request:
Additional metadata changed:
⛔ DNM label due to: 1 project with PR revision and 1 project with metadata changes Note: This message is automatically posted and updated by the Manifest GitHub Action. |
github-actions
bot
added
manifest
manifest-mcuboot
DNM (manifest)
erwango
force-pushed
the
fix_n6_flash_ext_app_upstream
branch
from
95dfb79 to
7eedd31
Compare
Instantiate a `soc-nv-flash` compatible node to allow using XSPI flash driver as a real flash controller on NOR device. Signed-off-by: Erwan Gouriou <[email protected]>
erwango
force-pushed
the
fix_n6_flash_ext_app_upstream
branch
from
7eedd31 to
5bab295
Compare
zephyrbot
added
area: Boards/SoCs
area: MCUBoot
area: Flash
platform: STM32
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
d3zd3z,
de-nordic,
djiatsaf-st,
etienne-lms,
gautierg-st,
juickar,
mathieuchopstm,
nordicjm and
rghaddab
etienne-lms
reviewed
Nov 20, 2025
erwango
force-pushed
the
fix_n6_flash_ext_app_upstream
branch
from
5bab295 to
c72d334
Compare
JarmouniA
reviewed
Nov 24, 2025
| spi-flash0 = &mx66uw1g45g; | ||
| zephyr,flash-controller = &mx66uw1g45g; | ||
| zephyr,flash = &mx66uw1g45g; | ||
| zephyr,flash = &ext_flash; |
Contributor
There was a problem hiding this comment.
More of a nit really, but ospi-nor-flash@0 node should not have the label mx66uw1g45g, rather something like ext_flash_controller, and consequently zephyr,flash-controller should be changed.
etienne-lms
reviewed
Nov 25, 2025
drivers/flash/flash_stm32_xspi.c
Outdated
Comment on lines
2209
to
2211
| /* Memory map could have been set by previous application */ | ||
| /* Abort to allow following card oriented transactions */ | ||
| /* If needed by the application, it will be re-enabled just after */ |
Contributor
There was a problem hiding this comment.
Nitpicking suggestion as this a single inline comment.
Suggested change
| /* Memory map could have been set by previous application */ | |
| /* Abort to allow following card oriented transactions */ | |
| /* If needed by the application, it will be re-enabled just after */ | |
| /* Memory map could have been set by previous application. | |
| * If so, abort on-going operations to allow following card oriented transactions. | |
| * If memory map mode is needed by the application, it will be re-enabled afterward. | |
| */ |
Member
Author
There was a problem hiding this comment.
Reworded, but in a different way.
Current driver protections prevent to initialize driver when run as from an external application running from ext flash. Aim is to avoid performing full driver initialization of the NOR flash controller the application is read from. But this problem is actually only valid when application is running in XIP mode (read in memory mapped mode at run time). In ram load mode, since there is no direct activity from the application on the NOR device, nothing prevents the ext flash driver to be used fully. Hence, we should allow the controller initialization to happen, with some adjustments. Mostly, what we need is to: - skip the hal init - abort memory mapping afterwards to let the jedec reading happen. Remove conditions around `stm32_xspi_is_memorymap()` and `stm32_xspi_abort()` which can finally be useful in various cases. Signed-off-by: Erwan Gouriou <[email protected]>
Point upstream mcuboot PR fixing stm32n6 fsbl variant configuration Signed-off-by: Erwan Gouriou <[email protected]>
erwango
force-pushed
the
fix_n6_flash_ext_app_upstream
branch
from
c72d334 to
1ed8b00
Compare
|
etienne-lms
reviewed
Nov 25, 2025
Comment on lines
+2196
to
+2197
| /* Memory-mapping could have been set by previous application */ | ||
| /* Force HAL instance in correct state */ |
Contributor
There was a problem hiding this comment.
/* Memory-mapping could have been set by previous application.
* Force HAL instance in correct state.
*/
Comment on lines
+2275
to
+2277
| /* Memory-mapping could have been set by previous application */ | ||
| /* Abort to allow following Jedec transactions, it will be */ | ||
| /* re-enabled afterwards if needed by the application. */ |
Contributor
There was a problem hiding this comment.
/* Memory-mapping could have been set by previous application.
* Abort to allow following Jedec transactions, it will be
* re-enabled afterwards if needed by the application.
*/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, STM32 XSPI flash driver initialization aborts if application is run from external flash.
Though, constraints are actually different if:
Fix XSPI driver to allow flash operations in RAM LOAD.
Make necessary changes on N6 DK to be able to make use of it.
Once approved, it will have to be extended to O/QSPI drivers.
Then, we should also make sure this work using MSPI drivers.
Edit: Depends on mcu-tools/mcuboot#2547